Alt System (WIP)

Battletech style!

Modules are volume-based. For instance, a ship might have 8 interior modules and 10 external. Larger ships might divide "external" into multiple sectors. Modules can be anything: reactor, life support, living quarters, cargo bays, carrier bays, and of course weapons and defensive systems. Module slots become a critical location chart of sorts.

Size retains its importance. Tech Level has fewer levels, escalating costs and resource demands: more like EVE. Improving ship capabilities independent of size and quality of module depends on crew skill (again, more like EVE).

Interior modules cannot take damage normally, but can be damaged on a critical hit, or if armor is compromised. Exterior modules can be targeted with a called shot. Inflicting significant damage on a module causes various effects: damaging the reactor will lower power, damaging engines will lower speed and maneuverability, ammo caches will explode, etc.

Power still works the same as 6.3: reactor output and capacitor are king. Reactor can vary greatly with module loadout.

Possible variables:

• Volume
• Mass
• Heat
• Cap
• Fuel
• Ammo
• CPU

Basically, the goal here is to make sure that the design of a ship affects its performance in a meaningful way. Given the same number of slots, two ships can have very different capabilities by configuring differently. A ship that can do everything will perform at each task inferior to a given ship specialized in that task. Simple enough.

The temptation to over-specialize in certain things, such as weaponry, is mitigated by a different factor: power. Etc etc

Ship concerns:

• Defense
• Maneuverability
• Speed over long distance
• Offensive power
• Cargo capacity
• Carrier capacity
• Life support / living conditions
• Endurance
• Special missions (ewar, surveillance, etc)

Essential systems:

• Frame
• Power core (reactor, battery, fuel cell)
• Fuel for power core
• Maneuvering thrusters
• Sublight drive
• Navigation sensors
• Comm array

Conditional systems:

• Repulsor array
• Hyperdrive
• Shield generator(s)
• Life support
• Cargo bay
• Carrier bay
• Weapons
• Tactical sensors
• Electronic Warfare systems
• Countermeasures

Core Skills:

• Pilot
• Slicing
• Mechanics
• Ranged Weapons
• Demolitions
• Knowledge (Tactics) ?

Goals and Mission

Mission:

• To create a system allowing for the creation and modification of starships in System 7 (or something like it)

Problems identified with SWSE rules:

• Too few actions for PCs to take
• Unbalanced roles
• Too few choices; mostly just rolling
• Starship-specific feats/skills/etc come at the cost of non-starship traits; balance isn't clear

Problems identified with S6.3 rules:

• Large numbers, complex math
• Possibly too many actions per round for single-PC ships

Proposed solutions:

• Ensure that starship combat and navigation involves all PCs, harnessing many skills equally.
• Focus on decision making at build time and action time, rather than dice rolling and calculation.
• Harness existing rules (that are useful outside of starship combat) wherever possible; allow PCs to invest in additional starship capabilities outside of normal PC build system
• Use simpler numbers and formulas, or provide computational tools to abstract and automate mathematical tasks
• Allow simplification of most systems (i.e. taking 10, convert roll- and math-intensive processes to automatic results)

Goals (in order):

• To make starship combat and navigation more fun
• To allow PCs and DMs to create and customize ships
• To make the starship rules fit with personal combat rules (numbers, sizes, etc)
• To make the system match the known Star Wars reality as much as possible
• To make the system obey physics (or at least theoretical physics) as much as possible

Not goals / deprioritized:

• To make the system match SWSE as closely as possible

Starship Stats

Basic Stats

• Determine ship size
• Choose modules based on desired capabilities
  • Focus on one area to maximize performance in that area, at the expense of others
  • Or, generalize, to handle all scenarios

To Improve

• Buy better parts (more money and/or greater access needed)
• Increase tech level (requires higher skill to use, cost/availability impact)
• Be more skilled (crew with more skill ranks; crew has group bonus from prior experience with same crewmates)
  • Possible starship feats and/or certifications

Basic Traits

• Size: the single most important stat. Figures into almost every mechanic.
• Tech Level: an upper limit on the tech level of modules. Even that can be bypassed, but retrofitted high-tech modules have some penalties.
• Frame: original frame was built for a certain purpose, and provides bonuses to the same, regardless of module loadout.
• Manufacturer: all manufacturers lean in a particular direction; manufacturer bonus applies slight modifiers (self-balancing).
• Crew: how many crew are needed.

Size

See Starship Size, hasn't really changed.

To-do: module slots per size

Tech Level

General

• 0: Outdated, obsolete, crap.
• 1: Basic, normal, run-of-the-mill, default.
• 2: Advanced, high-end, extra money.
• 3: Cutting-edge prototypes, way more money, restricted access.
• 4: Top-secret skunkworks projects, no sale price, highly restricted.
• 5: Alien, unknown tech.

Alternate

• Can have "special" tech levels, such as lost, ancient technology that is obsolete in many regards, but actually better at certain things, under the right conditions.

Effect of Tech Level

A frame with a higher tech level will have some general bonuses of modest extent. A module with a higher tech level will have very specific bonuses of greater extent. Fitting a tech X module in a tech X-Y frame imposes penalties, and requires more mechanical skill than fitting the same module to a proper, modern ship. Even with said penalties, the higher-tech module will work better.

Alternate Tech Paths

It's not always about passive numbers; the best high-tech modules never are. It's about breaking barriers, doing impossible things, or doing them in a totally different way (ideally a way one's enemies won't anticipate). Ideally, all high-tech modules will do something significantly different from the base tech module, not merely have better numbers.

Frame

Each frame has a general and a specific purpose.

General Purposes

Multirole Vehicles

It is possible to "multiclass", taking on multiple roles. Typically, serving multiple roles means being less well-equipped at each individual role than a single-role vehicle would be, but still better than a vehicle not intended for that role. In game terms, multiclass penalties apply.

Examples:

• The Acclamator- and Venator-class Star Destroyers are considered Assault Carriers, as is the Clone Trooper Assault Ship.
• The Victory- and Imperial-class Star Destroyers are considered Space Superiority Carriers.

Special Purposes

Frames often have a special purpose, unique to that frame. This is not selected from a list, but rather a special bonus only that frame has. (Rules note: sort of subjective for now, but should obey some sort of rules)

For example:

• The X-Wing fighter used by the Alliance to Restore the Republic had special long-range endurance capabilities to offset the lack of carriers in the early fleet.
• Most TIE craft have exceptional maneuverability, accomplished by sacrificing life support and shielding systems, but also by nature of their unique design, harnessing ultra-powerful miniaturized ionization reactors, necessitating massive radiators.
• The Acclamator-class Star Destroyer was built with landing capability, to deliver ground troops directly.
  • Later-model Trade Federation Battleships possessed a similar capability to detach their core module for the same purpose.
• The Jedi Starfighter was designed, under close Jedi supervision, to minimize impact to the pilot's concentration, and enhance the effect of certain Force Powers.

Special purposes may require certain modules. For example, a stealth craft might enjoy greater-than-average stealth capability, but not if its included stealth module is removed. Generally, these modules are integral to the design of the frame, and thus cannot be removed. For instance, an Acclamator's landing gear takes up considerable module slots; if removed, however, the slots cannot be used for any other purpose; the frame was not built to support any other conceivable module besides the landing gear--there would simply be a giant hole in the hull.

Crew

Crew needs vary depending on desired capabilities and size.

In general, "capabilities" refers to whether or not the vehicle is military. More specific detail is proved below; in general, military vehicles are expected to perform far more tasks, with the capability to reconfigure mission, self-repair, and constantly optimize, all for long durations, without the aid of external resources or time spent in drydock. This necessitates a much larger crew.

Ballpark crew needs

Capability Matrix

All general capabilities of a vessel can be effectively commanded by a minimal, skeleton crew--in many cases, even a single person--provided everything is in perfect working order. Automation is a complex business, and the larger the ship, the more can go wrong, especially in combat scenarios where well-tuned systems can become damaged beyond the ability of computers or droids to diagnose and repair.

In practice, this means that navigation (atmospheric, sublight, and hyperdrive, though the latter will require a navicomputer or astrogation droid if nothing else), basic engineering (power on/off of modules, changing reactor output), weapon and defense systems, and such normal operations can be commanded by a minimal crew from a command center. However, if and when something goes wrong, the time it takes to restore said functionality will be much, much higher with less than a full, military crew.

• For example, while a capital-sized megafreighter might be able to fly with only 10 crewmen, where a similarly-sized battleship might crew 10,000, should the main reactor of the freighter break down, it will take 10 crewmen perhaps hundreds of times longer to restore power, if it is even possible without outside help, whereas the crew of 10,000 would be expected to restore power in hours, or perhaps minutes.
• Another consideration is that over-reliance on automation creates an enormous vulnerability to electronic warfare. Jamming systems and ion weapons can disrupt automated systems, potentially denying access to virtually all functions of a vehicle; however, when crewman are manually operating these functions, such systems have little to no effect. The idea of a fully-automated battleship is ludicrous in today's battlefield, as a ship which can be rendered useless by a single ion cannon blast is not worth the time it takes to send a rejection letter to the designer.

Beyond the above considerations, there are more specific capabilities that are unavailable to ships relying on automation, such as:

• Reconfiguring ship systems in real time. Engineers in tactical vehicles are often asked to reroute power, compensate for disruptions and overloads, or boost reactor output for a brief period (presumably at a cost to maintenance later on). Such things require a staff of engineers ready and able to perform these modifications.
• Reassigning personnel to boost key systems. The high crew needs of some ships lead many to train crewmen in multiple roles. This creates the possibility of moving some crewmen to tasks more crucial to the vehicle's current situation, boosting those capabilities at the expense of others. This is not possible with automation; the capabilities of an automated system are hard-coded and cannot change.
• Most crucially to any PC crew: automated systems are only as adept as their designer, and mechanical and computational limits mean such systems rarely if ever outperform skilled operators. In game terms, automated systems always take 10, and have unchanging, relatively low skill bonuses. Most PCs of appreciable level can easily outperform such systems. For larger ships, PCs can assume leadership roles, granting skill bonuses to their crewmen, which automated systems cannot benefit from.
• Crewmen can learn; automated systems cannot. Crewmen gain experience by using their skills, and may receive additional on-the-job training in their principal field, or in other fields. A crew with low turnover will also accumulate group bonuses over time, reflecting their growing trust and reliance on one another. No automated system has such a capability.

Note: it is possible for droids to fulfill the role of "crewman", as opposed to being considered part of an automated system (or a tool used by a crewman). This was, of course, well-exploited by the Separatists during the Clone Wars, to varying degrees of success. However, this requires illegal AI programming (one of the Separatists' many war crimes), and/or illegally failing to wipe droid memory to ward against the possibility of sentience.

Modules

The only thing you get in a starship without modules is a frame: literally, an internal structure, maybe with an outer shell (if you're lucky). Everything else is a module. This necessarily creates a de facto divide between two types of modules: essential and optional. While weapons, shields, and hyperdrives might be nice, a reactor, sublight drive, and life support is usually held to be essential (although perhaps not the latter, in the case of fully-automated droid ships or certain cheap fighters).

Module Basics

Every module has a size, a tech level, a cost and availability, and of course a listed purpose. Many also specify an amount of power drained (see Capacitor) per use (or per time period, if toggled). Most importantly, all modules have a slot size, indicating how many module slots they occupy.

Module Slots

Each frame has a set number of module slots. All are the same size as the frame (a medium ship (size 5 or 6) has medium slots). The slots are usually grouped by position in the ship, such as "dorsal" or "starboard". The purpose of these groups will be detailed later. Simply put, a module takes up a certain number of slots, and these slots must all be contiguous, and in the same group. Additionally, any module which modifies another module (such as an ammunition module fitting into a launcher module) must be in the same group in order to work.

Module Power

Starships generate power from a power core (usually a reactor or fuel cell). Modules use power. But the power doesn't magically teleport to where it's needed; it must be routed there. And the more power that is needed, the more voluminous and massive the routing system will be.

To this end, each module is considered "high power", "medium power", or "low power"; while the balance between the 3 will vary, one will never find a ship where all modules are "high power". Irrespective of the actual power consumed by active modules, the simple fact is that a ship with all "high power" modules would consist of nothing but power routing, and have no room for modules themselves.

Using Modules

To use a module, it must first be online.

• Bringing a module online requires an action.
  • Typically, this is performed by someone in the Engineer or Operations role.
  • The time required, and any success criteria, are noted in the module's description. (Typically, it takes a standard action to activate a module. It is usually possible to activate multiple such modules at once)
  • A module will not come online if is destroyed or disabled.
  • Certain modules ignore this requirement, and are always "online". This will be noted in the module description. Common examples: hull plating, cargo containers, passive sensor arrays.
  • Bringing a module online may incur a one-time cost to Capacitor. This reflects the energy needed to initialize the module. For instance, turbolasers must first "spool up" a substantial amount of energy before being able to fire the first time. Subsequent firings incur a Capacitor cost; this combines the cost to fire, and the cost to recharge for the next firing.
• An "online" module does not perform any function until it is "activated".
  • There are two main types of activation: on-demand and toggled.
  • On-demand modules are activated at the time of use, for the duration of use. The most common example are weapons; firing the weapon is the same things as activating it.
  • Toggled modules are activated and deactivated at the will of whoever takes the action to do so (usually swift or free). Once active, they immediately begin having their usual effect, and drawing whatever power they need to function. Once deactivated, they cease their effect, and cease drawing power.
• Any time an action to bring a module online, or to activate it, is undertaken, should the action require CAP, and should that CAP not be available, all remaining CAP is drained, and the action fails. Furthermore, the module is placed in a "jammed" state, requiring manual intervention to discharge the wasted energy before it can be activated again.

Example:

• The CO of a Star Destroyer wants to fire his turbolaser batteries. To that end, he orders his Senior Gunnery Officer to bring the turbolasers online.
  • The turbolasers draw the necessary CAP.
• The SGO rolls the necessary check (likely a leadership roll to modify the otherwise hard-coded modifier for the gunnery and engineering crews). The guns come online after a few rounds.
• The commander orders his Senior Tactical Officer to plot a firing solution.
• The STO rolls the necessary check, modifying the hard-coded rolls for the sensor and tactical officers who are calculating the target's current and projected acceleration, velocity, and position, and cross-referencing with their weapons' acquisition, firing, and propagation speeds. On success, they report back to the STO, who reports to the CO. At this point, the final to-hit modifier to the attack roll has been determined.
• The CO orders the SGO to fire.
• The SGO passes on the order. Individual gunnery officers fire their weapons. The attack roll is made. The weapon fires.
• The turbolasers recharge, drawing the necessary CAP. However, the CAP is depleted before the final turbolaser battery can draw its power.
• Most batteries are ready to fire again; the last battery is jammed, and the on-site officers must pass the necessary skill checks to discharge the energy to render the battery usable again.

Damaging and Destroying Modules

Modules can be damaged or destroyed, independently of the vehicle as a whole.

Sections

The section in which a module is slotted determines how vulnerable it is to said damage. Sections designated with arcs, such as "ventral" or "starboard", are vulnerable to attacks from that arc, and no other attacks. Sections designated "internal" are not vulnerable to external attacks, unless the ship's shields and armor have been compromised.

Deliberate Attacks

An external module can be targeted deliberately by another vehicle's weapons. This typically increases the DC of the attack roll, as the module is a much smaller target than the ship as a whole. On a successful attack, the module sustains damage, and may be destroyed. Modules have far fewer hit points than the host ship, naturally. Furthermore, while the default is for modules to be protected by the ship's shields and armor (in terms of DR, SR, resist, absorb, etc), some modules specifically do not allow this (e.g.: a high-gain comm antenna must necessarily protrude beyond shield radius and not be covered by armor plates).

As a general rule, only an external module can affect the external world; thus, most weapons, sensor arrays, shield emitters, comm towers, and the like are external modules, and thus vulnerable to deliberate attack.

Critical Hits

Whenever a ship is critically hit, it is possible that the attack may damage a module. This can affect even internal modules. With a non-deliberate attack, the critical location is determined randomly (arc-based limitations still apply); deliberate attacks which are also critical hits simply inflict more damage on the chosen module. The damage to the module is mitigated by the current status of the ship's armor, shields, structural integrity, etc.

Note that "critically hit" does not necessarily refer to the attacker scoring a critical success on his attack roll; see below.

Critical Damage

Once the specific module affected by a critical hit has been determined, the damage can be calculated. The effect of damaging a module is specific to the module, and is determined by an abstraction, rather than a numeric damage amount. Specifically, there are three criteria for achieving a "critical hit" and thus damaging a module:

• The attacker scored a critical hit on the attack roll
• The attack inflicted damage equal to or greater than the defender's Damage Threshold
• The attack inflicted structural damage (armor and shields usually prevent this, unless depleted or somehow bypassed)

If one criterion is satisfied, the module suffers minor damage; if two, major damage; if three, critical damage. (Note: this is very similar to the Injury system)

Typically, "minor damage" will cause a simple numeric debuff, which is stackable. Such damage can be repaired in a moderate amount of time by skilled engineers (in cases of extreme skill and luck, perhaps even in mid-battle!).

"Major damage" will typically foul the module's prime purpose; while not rendering it useless, it will be much less useful. For instance, "major damage" to a gun turret might mean that the turret can no longer aim, but can still fire in its current direction. Repairing major damage is more time-consuming and resource-intensive than minor damage.

"Critical damage" will not only totally disable a module, but often cause catastrophic side effects. For instance, critical damage to an energy weapon can cause a sudden release of stored energy, damaging other nearby modules as if they, too, were critically hit. A critically-damaged module is rarely repairable, and will usually be scrapped, though a sufficiently skilled and lucky crew might restore it.

Special case: ammunition modules are highly volatile. They are likely, when damaged, to explode, causing grievous structural damage (which will then damage other nearby modules, possibly causing a chain reaction if they, too, are ammunition modules). The likelihood increases with the severity of damage; for critical damage, this is certain to occur.

Implications for Starship Design

Module selection determines almost every important detail about a vehicle's capabilities, so proper selection is paramount. The module system forces a starship designer to make tough decisions about which capabilities to prioritize; sure, it would be nice if every ship was fast, tough, heavily armed, stealthy, long-range, and luxurious, but that's simply not feasible. The old adage "jack of all trades, master of none" applies all too well to a vehicle with too wide a focus in module selection.

Since most frames have a special purpose, and virtually all have a general purpose, it is usually sensible to match module loadout to the intent of the frame, not to mention the traits of the manufacturer. The module system gives designers freedom to create variant models, and ship owners the freedom to customize their ships (legally or otherwise); it is not intended to allow every ship to transform into any other ship with a simple refit.

To that end, frame modifiers are usually quite extreme. For instance, an Assault ship might have a 25% CAP reduction and 25% bonus ammo capacity for all weapons systems, while a Transport might offer +200% cargo capacity. Meanwhile, any MandalMotors craft might offer 2 bonus module slots for weapons only, while a Theed Palace Royal Engineering Corps vessel offers automatic upgrade of luxury units and a bonus to all maintenance checks and automated systems. Ignoring such bonuses would yield a very sub-par vehicle.

Not only is module selection important, but placement matters greatly. For instance, placing all weapon modules in a certain arc might mean that the ship has no ability to attack enemies in other arcs. As ridiculous a situation as this seems to be, it is in fact a famous design flaw in the Imperial-class Star Destroyer, which cannot project any prime weapons system into its rear arc; the fact that it is less maneuverable than virtually every other warship in the known galaxy means that any ship attacking an ISD will invariably attack from this vector. (Rumor has it that KDY is fast-tracking a retrofit which, among other things, offers barbette mountings for turbolaser batteries to offer some coverage of the rear arc, as well as more powerful rear shielding to nullify all but the most powerful attacks from that direction)

The possibility of radiant damage on critical hits also means it is a good idea to space out critical systems. For instance, a ship with two shield emitters ought not place them side-by-side, as critical damage to one might also destroy the other, but only if they are adjacent. By a similar token, it is quite inadvisable to place more than one (or very few) ammunition modules in close proximity to one another.

Power

Next to an intact frame and shell, power is the most important trait for a vehicle to have. Without it, the vehicle is motionless, and without capabilities of any kind, including life support.

Power Core

The generic term for a ship's power source is its "power core". This term is often replaced by a more specific term, such as "reactor" or "fuel cell".

Regardless of type, a power core always fulfills the same purpose: to generate power. In a physical sense, "power" means "the continuous production of energy". A power core produces energy constantly, consuming fuel at a commensurate rate. This power is then routed to systems that need it. Or, more commonly, power is routed to a temporary buffer, from which modules ultimately draw their power.

Capacitor

For many reasons, the vast majority of ships for which high and/or variable power consumption is a concern (read: all ships participating in combat (read: all ships PCs care about)), it is sensible to store the output of the power core in a buffer called a Capacitor (abbreviated as CAP). A Capacitor stores energy, generated by the power core; it can store far more energy than the power core can generate in a second, or even many seconds (or minutes). What this means is that a ship can draw more energy per unit of time (aka "power") than its power core can possibly produce, as long as they only do so for a brief period (until the capacitor runs out).

Capacitors work in a number of ways. The simplest types simply store electric potential energy, filling up with electrons (typically) until a certain threshold is met, then staying at maximum until energy is drawn, after which it can fill up again. More complex (read: larger) capacitors use other technologies, such as flywheels (storing energy in kinetic form), plasma batteries (storing energy in thermal form), or even exotic devices such as gravitic capacitors, which store energy as standing waves of space-time distortion. Hypermatter annihilators, a common reactor in very large vehicles, use an ongoing fusion reaction as both the "starter" for the primary reaction, and as the capacitor for the energy it produces.

Mechanically, a capacitor stores energy, measured in variable units. A smaller vehicle might store megawatt-hours (MWh), while a larger will store GWh, TWh, or even PWh. Since the unit never changes for any given ship, it is usually just read as a unitless number (such as "500"), or as "500 CAP".

All modules draw their energy from the Capacitor, not from the power core. At any given time, 100% of a power core's net output is used to charge the Capacitor. For the purposes of this system, the Capacitor is 100% efficient: no energy is lost by transferring into or out of the Capacitor. Thus, there is no drawback to this method, in terms of harnessing all available power.

The meta-purpose of the Capacitor is to extend the already interesting minigame of power management by adding time pressure. Reliance on CAP means a ship can only operate at full power for a very brief period. Compared to alternate approaches, such as tweaking reactor output by a certain percent to this or that system, it is both more realistic (reactors don't just spool up or down at a moment's notice) and more mechanically solvent (boosting system A does not require recalculating the effect of systems B-Z; instead of multiplying fifty numbers by 97.5%, you're just spending a bit more energy once).

In-universe, one might question the use of capacitors, given their tendency to run dry and leave you hanging. There are many reasons for this, not the least of which is simply that using a Capacitor gives you the option of drawing more power than your reactor can possibly generate, with no drawback should you choose not to exercise that option. Others include:

• Weapons vs Shields:
  • Static shielding (i.e. shielding that uses a set amount of power, drawn constantly from a reactor) will always defeat static weapons drawing the same power.
  • This may or may not be physically likely, but for the purposes of game mechanics and drama, it must be so; otherwise, every ship every would be invulnerable to any similarly-sized ship--rather than arming with weapons, they would simply put all available power to shields and waltz through the battlefield, impossible to harm or hinder.
  • The use of a Capacitor allows a weapon to spool up a burst of instantaneous energy, transferring far more energy per unit of time than the defender's static shield can absorb.
    • A static weapon would take the form of an "always-on" energy transfer, such as a laser beam. This thus creates the simple comparison of weapon power vs shield power, which the weapon always loses, as mentioned above.
    • However, by concentrating energy into a brief period of time, such as focusing several seconds' worth of reactor power into a turbolaser bolt that will confer all of its energy in a millisecond, the energy/time ratio is greatly upset. Such a bolt offers thousands or even millions of times as much energy transfer as a static shield could absorb.
    • Indeed, this development utterly obsoletes static shields. All modern shields are active defenses, save for those intended to block attacks far weaker than the host ship could itself generate (i.e. a capital ship's close-in shields to block fighter attacks).
    • Active shields "spool up" their energy, releasing it bursts, timed to oppose incoming attacks. The specific mechanics of this action are quite complex; suffice to say, it explains why shields can be overwhelmed with salvo fire, and why they tend to draw CAP in bursts, rather than as a constant drain.
    • More information: Active Shields (WIP)

Starship Action

Technically, starships, and all other vehicles, are no different from any other participant in combat or action scenarios. However, there are three major ways in which it can differ:

• Vehicles can sometimes take more actions than a character. Technically, each character commanding a portion of a vehicle takes their own actions on their own Initiative.
• When an action scene is comprised of mostly or entirely vehicles on the starship scale, it is recommended to change the size of "one square" to match the size of a medium starship, not a medium creature.
• Whenever action occurs in space, there are certain conventions used to help manage action in three dimensions with highly variable velocity and positioning.

Commanding a Vehicle

In starship/vehicle action scenes, each character takes actions on their turn, just the same way as if they were not in a vehicle. However, being in command of a vehicle allows additional actions.

Vehicles are widely variable. Below is a list of common positions:

• Pilot
• Co-Pilot
• Gunner
• Tactical Officer
• Operations
• Engineer
• Repair Technician

A brief list of almost-universal actions allowed by vehicles:

Roles vs Actions

In truth, most ships allow for anyone to perform any role. A pilot might take command of weapons and shields, or pass that off to a gunner so he can handling engineering tasks, etc. Only in the largest vessels (i.e. capital ships) are command duties so complex that it is impossible to handle every role from a single station. This is reflected in the ship's minimum crew limit; if the minimum is 1, and the maximum is 5, then 1 person could handle all tasks from a single station, or as many as 5 could share tasks, with 5 stations.

Crew limits are mainly imposed for the sake of realism; the real limit on combining roles is that characters can only take so many actions per round, and the total number of useful actions that could be taken in a given round is almost always greater than that number. In starships, two heads are better than one.

Ultimately, it is sufficient to assume that any number of characters (within the crew limit) can perform actions independently of the others, without worrying about each character's role. Of course, ten pilots cannot make a ship go ten times faster; as a general rule, the same component of the ship (drive system, specific module, power system, etc) cannot be used twice in a given round, regardless of the number of characters attempting the action.

If a more specific approach is desired, then each vehicle should defined the exact number of stations, where they are in the vehicle, and which roles can be filled at which station. For example, the Millennium Falcon:

• Two stations in the command deck both allow for the Pilot, Operations, and Tactical role.
• The bridge stations can fill the Gunner role, with limitations; the Falcon's two turreted quad lasers must be fire-linked with the coaxial lasers, negating the function of the turrets for aiming, and replacing their agility modifier with the ship's maneuverability modifier (which is necessarily lower).
• Each turret is a single Gunner station, and cannot fulfill any other role.
• A virtual station in various places within the vessel allows performing the Repair Technician or Engineer role. As many as 3 characters could fill this role simultaneously; any more and they would just get in each other's way.

Command vs Control

In most vessels medium and smaller, taking a role means manning a station and taking direct control of a shipboard system. In larger vessels, crew rosters can be much higher, and such positions usually take the form of ordering an array of inferior officers to perform tasks.

For mechanical purposes, a Command position, as described above, works the same way as a Control position; the character in that position rolls skill checks and expends actions, as normal. However, such vehicles usually have a "crew modifier", reflecting the training of the crew. An officer highly-skilled in piloting will outperform one with less skill, other things equal, but both will be hindered by an actual helmsman who lacks skill.

Larger ships also impose a size penalty on such skills, reflecting the difficulty of coordinating dozens, hundreds, or even thousands of underlings to carry out one's orders. Typically, the goal is to maximize crew bonus so as to offset size penalty. This means that larger ships will require exponentially more crew training to achieve the same results as smaller ships.

Vehicle Scale

It is always permissible to use the standard 2m square for mapping action scenes with vehicles. It just isn't always practical.

In theory, it is possible to adjust the size of a square to any desired number of meters; in practice, it is best to avoid confusion by limiting the number of scales in use. Thus, the only other recommended scale is the Starship Scale, in which a "medium" vehicle occupying 1 square is, in fact, sixteen times larger than a "medium" character on the Humanoid Scale, and thus a square represents 32 meters on a side.

This works well enough when planetside, or when combat is happening relative to some enormous, relatively stationary object, such as a space station, but what about in space, where velocities can measure in the hundreds, thousands, or even millions of squares per round?

See Action in Space.

Action in Space

Battle maps are usually stationary; the surface of most planets does not move unexpectedly on the scale of rounds. But when action takes place in the vacuum of space, there isn't always a convenient stationary object to serve as a foundation for the map. This isn't helped by the ability of spacecraft to travel at speeds many orders of magnitude higher than ground vehicles, creatures, and even aircraft in an atmosphere.

There are two basic ways to handle this:

• Ignore physics, and force the game to conform to ground-combat norms
• Obey physics, and embrace the realities of Newtonian motion in three dimensions

While it is tempting to choose the former, imposing changes on physics to force space combat to resemble combat in an atmosphere, it is not preferable, because for all the ease of use that might offer, it ultimately means sacrificing many things to make space combat exactly the same as ground combat. If it is the same, then why bother with it at all? If it's going to be different, let it be different.

And thus, the reality approach.

Crash Course in Newtonian Physics

Aircraft appear to have a "top speed" because, while their engines can only produce so much forward thrust, the force of air resistance increases in strength the faster the aircraft goes; at a certain speed, air friction pushes against the engines, exactly matching their force, and the vehicle's speed can no longer increase.

This, of course, does not happen in a vacuum. There is no force to resist an engine's thrust; thus, a vehicle applying constant thrust will continue to accelerate forever (or at least until it approaches the speed of light). Furthermore, since a vacuum offers no resistance, the vehicle's speed will not change if it deactivates its engines; it will simply coast at the exact same speed, in the same direction, forever, or at least its engines, or some other force, pushes it in a new direction.

Designers of games involving space combat often avoid this reality, fearing that it is too complex, and preferring the more intuitive reality of the behavior of aircraft in an atmosphere. This approach is wrong for a few reasons:

• It ignores the fact that most people playing these games are nerds, and most nerds understand basic Newtonian physics by now.
• It ignores the fact that the spacecraft they are simulating are not aerodynamic, and would not obey the laws of aerodynamic motion in any case.
• It ignores the fact that virtually all modern combat craft can accelerate far faster than needed for the kind of maneuvers the designers envision craft performing.

This last point is perhaps the most overlooked. A 21st-century jet fighter, at maximum thrust, is quite capable of outperforming its own pilot. In other words, just about anything the pilot does with the controls while at full throttle, besides a very narrow range of carefully-controlled maneuvers, would knock him out and cause the vehicle to crash. Knowing this, pilots train to perform specific maneuvers, not always at maximum thrust, but at the exact rate of acceleration they need to perform it.

A starship would work the same way. The ability to accelerate forever and achieve phenomenal speeds may be useful for interplanetary travel, but it is not useful or relevant in space combat; spending three hours building up speed, only to whiz by a space battle in a microsecond, is completely pointless, and therefore isn't going to happen. Rather, pilots would be trained to perform specific maneuvers, using specific acceleration to achieve the desired result...exactly like a 21st century fighter pilot.

In any case, this system asserts that the time has come to abandon all attachment to false physics, that players do not choose to play a space combat simulator without the desire to actually experience space (and if they do, they're stupid, and fuck 'em).

How Newtonian Physics Applies to Space Combat

The Net Effect: or, Piloting is King

Tactical manuals and dogfighting disciplines talk a big game about statistics, and how the smaller vessel always wins the Size Effect. But those comparisons always take place in ideal scenarios, in ridiculous 1-on-1 confrontations. Real combat is complex. There's a lot going on. People are afraid they might die. And so the ideal numbers don't always hold up. There's a lot of room for skill.

In mechanical terms, that means that maneuverability isn't a magic bullet; it's going to come down to a skill check, which not only includes your skill as a pilot, but also has room for some good ol' fashioned luck (which PCs tend to be very rich in).

See below for more crunchy details. But first...

How to Make a Map of Nothing

Battle maps work best when there is a stationary frame of reference (i.e. the ground, the surface of the Death Star, etc), and when the tokens on it don't move particularly fast, or outside of a certain radius.

In space combat, that all goes right out the window. You're constantly accelerating in all sorts of directions, so your delta-V is about as easy to predict as the Butterfly Effect, and just forget about calculating position. If you actually do have some sort of stationary frame of reference, like a host ship, and you engage in a dogfight for a few rounds, you could be fricking anywhere when that fight ends.

Indeed, that is a serious problem in large battles; squads of fighters are constantly monitored by command officers back home, and warned when they are drifting too far away from their carrier, or from wings that can support them. Of course, position isn't king in space: acceleration is. Being "far away" from home base and "close to" a new group of enemies isn't much of a threat when you are more maneuverable than they are; with some advance warning, you might as well be in Timbuktu.

But again, those are ideal situations. The reality is that space is chaotic, and takes place in a spatial paradigm that humans are not equipped to understand intuitively. So they boil it down to this: conveniently an abstraction that works well for game mechanics...

Home Base

Where are you? That depends. Your position is always relative, so it helps to have something to call home. For any given scenario, every pilot has exactly one "home base". This is a vehicle or installation that serves as the "center" of the "map". Usually, it's the biggest thing on the battlefield, as, since everything else is more maneuverable, its own maneuvers are negligible, and it can just be assumed to be stationary.

• As such, there exists a Battlefield Map, describing the relative position of every vehicle in the battle, with Home Base at the center. It isn't always a displacement map; depending on the scenario, it may be a velocity map or an acceleration map, or even something more exotic. More often, it is a simplified map describing which vehicles are engaged with which.

Engagement

Two ships heading in different directions, at different speeds, at different acceleration rates, might as well be in different universes. They are "engaged", so they are extremely unlikely to interact in any way. Engagement refers to the situation where multiple ships match their position, velocity, and acceleration to one another. This can be an exact match, as in formation flying between allies, or a match intended to produce advantage, such as obtaining a Range Lock or an Orbit. Regardless of the setup, all ships engaged with one another are said to be in a single "engagement".

• Engagement is contagious. When you are flying in formation, you are engaged with your wingmen. If an enemy attacks one of your wingmen, he has engaged with all of you, and all of you have engaged with him. If he has his own wingmen, they're invited to. Everyone is engaged with everyone, and the whole collection is one Engagement.
• A typical battlefield map will show one or more engagements. In all but the smallest battles, the engagements will be distant enough that interaction between them is virtually impossible. Moreover, the requisite size of the battlefield map (if using a displacement map) is so large that each engagement occupies a tiny area, perhaps no more than a virtual point (or a literal pixel).
• Each engagement has its own Engagement Map.

Engagement Map

A map describing all combatants in an engagement, and their relative positions to one another.

• First things first: forget about an absolute position map. When you've got a wing of TIE fighters orbiting an X-Wing, and he's got his own wingman trying to counterattack the TIEs, and everyone is juking around to evade and gain advantage, plotting an absolute position map is a hopeless task. A relative position map is not so hopeless, but care must be taken.
• To establish an Engagement Map, first establish a Wing Leader. Anyone flying in formation with the wing leader is part of the engagement. An ally who isn't is not really in the engagement, per se (unless he's attacking one of the Wing Leader's enemies)...look ahead to Sub-Engagements, or just keep reading.
• Each side will have a Wing Leader. This isn't necessarily the titular wing leader, as appointed by whatever brass is in charge of each side. If the PCs are involved, they will just choose whoever to be their leader. And if the PCs are on the offensive, then whoever the PC leader chooses to attack is now the enemy "wing leader".
• Once each side has a leader, it is possible to establish relative positioning. As has been discussed, there are really only a few possibilities here: Range Lock, Jousting, Orbit, etc. Most all of these require determining who has positioning advantage.
• Gaining positioning advantage is an action requiring an opposed Piloting check. Maneuverability applies, obviously, and being range locked already puts one at a further disadvantage. Once won, advantage is maintained until voluntarily given up, or until the opponent takes it back.
• Once the side with advantage is determined, the winner decides the relative position. He can range lock, joust, play chicken, or whatever. Positioning is determined first.
  • You might be wondering: how long does it take to achieve range lock, or charge, or whatnot? The answer is: who the fuck knows? There are so many variables, it's just ridiculous to consider them all. In space combat, a "round" is however long that takes...within reason.
  • "But if a round can take 3 seconds or 3 minutes, then shouldn't all sorts of things change as a result of the duration varying?" Aw, can it, I said "within reason". Generally speaking, if two ships are close enough to start trying to vie for position, they're close enough to shoot each other. So all the time that they're not doesn't really count. If two ships are seriously too far to engage yet, then they aren't in Engagement Time yet.

How the map looks:

• Each Wing Leader is represented on the map. They are positioned to reflect the positioning that the winning pilot chose.
• Each side has a "formation box" showing any wingmen attached to the Wing Leader. All wingmen are represented in their side's box. (Note: their position might reflect the specific formation, if that is ever implemented)
• There may be zero or more Sub-Engagement boxes, representing wingmen who have broken formation to attack enemy targets still in formation.

Engagement Time

Engagement Time is the fastest-paced time in space combat. In Engagement Time, seconds count. Actions taken here take as long as you're used to them taking: a few seconds, at most. This is the time in which most time-sensitive things occur, such as CAP recharge, module cycling, ship maneuvers, etc. Medium-range travel, such as that which gets you from one engagement to another, takes place on in Battlefield Time, and long-range travel, such as a hyperjump to the next star system, takes place in Navigation Time.

Combat in an Engagement

The basic round structure:

• Everybody goes on their Initiative, regardless of which Engagement they're involved in. Every character involved in a battle is on the same Initiative chart, and they all get one turn per round. This keeps things fair, and also is exactly the same way ground combat works, for the sake of simplicity.
• On a pilot's turn, if he is the Wing Leader of a side, he may attempt to gain position, if he didn't already have it. That's a pretty standard Piloting check. It's just one of many things he could do.
• Succeeding on a Piloting check to gain position assumes complete success of the type of positioning. For instance, achieving a range lock of 10 km happens as soon as the action completes successfully. If that's a move, then it's a move. Go ahead and use remaining actions.
• When the opponent's turn comes around, he begins in the same position you left him. So, if you had him in a range lock, then he's in a range lock. He can try to Pilot his way out of it, establishing his own range lock. If he succeeds, then it happens, and he can use his remaining actions afterward.

Sub-Engagements

When an engagement involves wingmen, things can get tricky. By default, wingmen are in formation around a Wing Leader. Thus, wherever he goes, they are assumed to be in formation. That's easy enough. (Note: there may or may not be specific mechanical benefits of certain kinds of formation. It may just be abstracted out; for instance, the proper formation for TIE wingmen in an Orbit is very complex, but has the net effect of giving them exactly the positioning as the leader).

But what if you want to deploy a wingman to sucker-punch your enemy from the back? Or perhaps to divide his ranks, the better to conquer? You might be thing you could just splinter off a new Engagement, but...what if the sucker-punch target doesn't want to stop engaging with you, the leader?

Thus, the Sub-Engagement:

• A Sub-Engagement takes place in the same position as its parent Engagement on the Battlefield Map.
• On the Engagement Map, remove the wingmen who are starting the Sub-Engagement from the formation box, and place them in a Sub-Engagement box.
• In the enemy formation box, indicate who their target is. It might also be the enemy wing leader.
• From here, everything proceeds as normal until someone in the sub-engagement group gets a turn.
• On their turn, they may attempt a Piloting check to establish position on their target.
  • Typically, this means getting behind the target, at optimal range. In general, the goal is to take the most advantageous position, and the assumption is that remaining in formation was not that position. (If it was, then just stay in formation; there's no need to start a Sub-Engagement)
  • If they succeed, then they have achieved position on the target. Place a duplicate token of the target in the sub-engagement box and use normal techniques to show relative position. (That just means indicate facing and range, pretty much)
    • Why a duplicate? Because the enemy is still in formation. If desired, your Wing Leader or any wingmen still in formation could still attack the target, albeit with the positioning that they have, not the one the sub-engagement established.
  • If they fail, they haven't achieved position. Don't move any tokens around.
    • Note: "achieving position" just means you get to choose your attack vector and range. It is always possible to shoot without achieving position. That just means the exact range, delta-V, and vector is determined randomly.
    • More specifically, most of the variables are eaten up by the d20. Range is assumed to be "close enough", i.e. "at some point, you probably were within range, and range is pretty variable anyway, and the d20 can cover any other variables". However, this prevents you from targeting a specific arc, shield quadrant, or module; of course, the enemy also doesn't get to present a favorable arc either. If you get a crit anyway, the location is totally random, instead of determined by vector. (Note: it may be worth it to determine your firing arc first; this could have implications for turret gunners and the like)
• On the target's turn, they have a choice to make: stay on target and suffer these fools who are taking pot-shots at your butt, or break formation and show 'em who's boss?
  • In other words, at the target pilot's option, he can attempt to achieve positioning on his attackers. As soon as he makes this call, remove him from formation; he's not there anymore. If he wasn't already, place him in the sub-engagement box
  • If he succeeds, adjust the positioning of the box accordingly.
  • If he fails, resume prior positioning. If they didn't have position on him, then it's all just random. If they did, then they still do. He doesn't go back in the formation box.
• Anyone in a Sub-Engagement box may take an action to rejoin formation.
  • If said pilot was in a disadvantaged position, he still is; his enemies in the box can still attack him.
  • If he had advantage, he must give it up to do this.

Sharding

If a Sub-Engagement box goes too long without being tied to either Wing Leader, it will eventually "shard" off into its own Engagement.

• At the end of each round, check all Sub-Engagement boxes. Any boxes not currently involving targets still in formation (leader or wingman) have a 20% chance to fracture off into their own Engagement.
• Should this happen, remove all Sub-Engagement tokens from the Engagement Map completely, and establish a new Engagement Map. Elect new Wing Leaders.
• Rejoining the original Engagement is no longer a simple action, and requires travel on the Battlefield Map in Battlefield Time.

Vehicle Attributes

We all know about frame, size, modules, yada yada. Let's get down to brass tax: actual, final, useful combat mechanics.

Others not covered here:

• Tech Level: already factored into other numbers. For the curious: X-Wing 2, TIE 1, ISD 2.
• Crew Bonus: specific to a ship instance, not class, and irrelevant to 1-person ships.
• Bureaucracy Penalty: specific to capital ships, and also to instance, not class.

Pilot Skill Uses

Gunner Skill Uses

Specific Modules